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(57) Abstract 

A digital private key storage means (40) containing a user's digital private key; a cryptographic engine; a communicaUons port for 
receiving digital data fixxn an external device («), and for transmitting data to said external device (42); a display means (46) for displaying 
said received digital data; a user operable input means (44) connected to said cryptographic engine to indicate when operated by said user 
dieir approval of said displayed received digital data;.wherein said cryptographic engine is trusted to only apply said user's digitd private 
key to sign received data on^ if said user operable input means (44) is operated, and to communicate said signed data external of said digital 
private key protection device (40). This arrangement secures die user's digital private key from end point attacks by trojan horse programs 
by virtue of the fact that the private key can only be accessed via the user operable input means (44) which cannot be circumvented by 
software control. 
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HIGH ASSURANCE DIGITAL SIGNATURES 

This invention relates to digital signatures and in particular to high assurance 
digital signatures. 

Background 

Signatures are used by people in all aspects of everyday life. As society moves 
inexorably into the age of computers and information technology, the need for a 
signature which can be used in the digital realm is rapidly becoming a necessity. 

Digital signatures however are not new and have been described in the research 
literature for nearly 20 years, but are not yet capable of being described as 
"commonplace". 

However, as more security critical information is exchanged digitally, and more 
importantly flie economic value of the information and transactions being 
handled digitally becomes more important, the need for a secure digital 
signature is likewise increasing in importance. 

For the use of digital signatures to become readily accepted in high value or 
high-risk applications, it is necessary for them to be secure and there are a 
number of aspects to this security which are necessary precursors to tiieir 
commonplace use in the future: 

1. . The cryptographic algoriflims used to generate signatures have to be 
complex enough to be unbreakable; 



wo 00/31644 



PCr/AU99/0105I 



2 

2. The users of the system need to have confidence in the public key 
distribution infrastructure; 

3. The storage of private keys needs to be secure; and 

4. The " endpoint" at which encryption is performed and signatures are 
created or validated needs to be secure. 

The Uterature describes numerous successful attacks against security measures 
taken to ensure the abovediscussed issues. 

The invention described herein relates in particular to the fourth aspect of the 
security issues mentioned above, by providing a secure "endpoint- for 

encryption and the creation and validation of digital signatures. 
Endpoint attacks 

Endpoint attacks affect the act of encryption and the creation or vaUdation of 
digital signature, consequently the possibility of Endpoint attacks lower the 
confidence of the recipient of a digital messages that the message has been 
properly signed. The recipient may be unsure as to whether the digital message 
iginal or indeed originates from the purported sender of the message. 



IS one 



An endpoint attack is different to a "protocol- attack which typically occurs 
duringthetransitofthemessage. In an endpoint attack, the attacker typically 
alters software on a sender's computer, so that the altered software modifies one 
or more messages which are being sent and received or initiates the sending of 
messages without the knowledge of the sender. Whereas in a protocol attack, an 
attacker eavesdrops on communications between the respective computers of the 



wo 00/31644 



PCT/AU99/0I05I 



3 

sender and receiver and can impersonate either of the participants, or modify 
missives, etc. 

There exist encryption techniques which can reduce or eliminate protocol attacks. 
However, endpoint attacks in the critical area between the user and their own 
computer are not aided by tfie encryption approach. 

High assurance security and Endpoint attacks 

Technology for building secure systems has mostly been developed in the 
military intelligence commimities. In high-risk situations, policies require high 
assurance systems. That is, the users or owners of systems have to be highly 
assured, or confident, that ttie software and hardware systems they use will 
perform correctly. The consequences of failure can be so significant, ihat it is 
justifiable to spend substantial amoimts of time and effort to achieve this 
assurance. 

Assurance of this type is aimed partly at countering the threat of endpoint 
attacks and such assurance can be gained in a number of ways^ 

The most rigorous and objective methods, used by military and intelligence 
organisations, are described in publications such as TCSEC, ITSEC, and CC 
which provide a variety of physical, procedural and hardware and software 
approaches v^hich for this specialist environment can provide the necessary 
assurances. 

However, the majority of computers and computer systems used in critical 
environments do not meet the high levels of assurance which might be required 
by policy. 
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History has shown that the pioairement of suitably secure and assured general 
purpose computer systems is very expensive and impractical. They are typically 
obsolete before they are delivered. 

A device which provides high assurance digital signatures used as a limited- 
functionality peripheral provides a means for achieving high assurance security 
functions v«thout the disadvantages associated with the development and 
evaluation of a much more complex, general purpose computer system. 

Digital signature semantics 

Signatures in the "paper" world (in contrast to the purely "digital" world) are 
used to indicate that the person who signs the docmnent has written or read and 
thereby agrees with the content of the document and in accordance with its 
content, is bound by the fact of the signature to abide by that content The term 
signature can also include the mark of a legal entity which may be represented in 
the form of a company seal applied by an authorised officer of the legal entity 
and typically countersigned by that person. Documents requiring signatures 
include, but are not restricted to, personal letters, contracts, or cheques. 

Although there are many (surprisingly simple) ways to forge a signature, or 
undetectably modify the document which was signed, in critical circmnstances 
there do exist weU accepted procedures to increase the assurance that a signature 
has been applied by the appropriate person and that they were not under any 
duress at the time (eg witaesses). 

Thus it is desirable that, when digital signatures are used for the purpose of 
positively identifying the person who applied the digital signature, the signed 
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digital message/document has the same legal value and effect as signatures used 
on a paper document. 

As with paper documents, if a digital document is signed by a person or a legal 
entity, the recipient and reader of the document should be able to safely assume 
that the signer has written or at least read and agrees with the content of the 
document. 

However, in a digital world it is even easier than in the paper world to change 
docimients without detection, least likely but most importantly the creator of the 
(unsigned) document. 

In the digital world attacks occxu: almost instantaneously and in a realm not 
physically examinable by its users, attacks can originate from those very same 
devices that users grow to rely on, "tiieir ovm computer" and in a manner which 
can leave little, if any, no evidence of the mechanism or the attacker. Thus in the 
current digital world it is prudent not to place too much reliance on the veracity 
of a digitally signed message or document 

Assumed threats 

There are many computer systems today which can generate digital signatures 
for use with documents but they are all still vubterable to "endpoint" attacks. 
The designers and users of digital signing programs are often unaware of this 
tj^e of threat and for those that are aware, the confidence or trust that a recipient 
can place in the fact that a statement was signed is never high and potentially the 
whole system of digital signature and certificates will be placed into jeopardy if 
this threat is not properly addressed. This jeopardy increases as time passes by. 
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surety of the current system. 

1 A -orivP endpoint threat is exemplified by the 

compu«bemg»sed.by(sur^«^«^ ^^^^ 
legitiinatesoftwarc program and once ensconce 

^clousf«nctton»,wi*ou.*el»owWgeo<*emer. 
invention. 

This i. a »eU known «t "escribed in man, references. 

^ ^ kev crvptosystcms), the encryption and 
,„s«ndard(s,mme»c.ors«^ey=^^^^^ 

decrypaono^-onsusea^s^^^ ^ ^^^^^ 

. . w.^«"n«blic"keYandtheothera"pnvate key. The 
derivethatprivate key given thepublic key. 



wo 00/31644 



PCT/AU99/0105I 



7 

It is genarally assumed that any participant in information exchanged can 
acquire a user's public key, but that the user will protect the private key to the 
best of their ability. 

If the public key is used to encrypt some information, only the holder of the 
private key will be able to decrypt the information. This is useful for encrypting 
messages destined for a particular user, which should not be disclosed to any 
other user. If the private key is used to encrypt some information, any user will 
be able to decrypt the information with the public key. This will assure other 
users that it was only the holder of the private key who actually encrypted the 
message originally. This is useful for implementing a digital signature which 
comprises the transformation of the message using tiie private key to produce a 
string of digital data which uniquely represents the message and from which it is 
infeasible to decrypt the original message. Only the other of the key pair, in this 
case the corresponding public key, can determine whether the original document 
was used to create the signature. Furthermore, it is also possible to encrypt a 
message with a public key which can only be decrypted with the corresponding 
private key. 

The use by a user of their private key is seen by most as the equivalent of 
physically signing the content of the message, as it is typically assumed that only 
the holder of the private key could enaypt it and only the public key could 
decrypt it. This also of course assumes that Ae public key verifiably corresponds 
to tiie private key. 

For efficiency purposes, encryption of messages is frequently performed by using 
a symmetric algorithm (which is faster) to encrypt the message using a randomly 
generated message encryption key, then using the asymmetric algorithm to 
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encrypt the "message encryption key" with the recipient's pubUc/private key. 
Only the recipient, with a corresponding public/ private key, wiB be able to 
decrypt the "message encryption key", with which they can then decrypt the 
actual message. 

Sumlarly, for signing a document, it is usual to calculate a "message digest" 
using a hash function. It is the digest (which is much shorter than the message) 
that is then encrypted with the signer's private key. This encrypted digest is 
called the signature. A recipient can decrypt the signature to recover the original 
digest value. The signature is vaUd if the hash of the message is equal to the 
decrypted signature. 

Cryptographic Engine 

A cryptographic engine is an electronic component which is able to perform the 
complex arithmetical and logical manipulations involving data and keys, to 
implement encryption, decryption, signature generation, and signature 
validation. A cryptographic engine may include a number of registers for storage 
of keys and/ or intermediate results. 

The designer of a cryptographic engine would typically expect that the engine 
would be used to perform various calculations in order to give senders and 
recipients various assurances about the confidentiaUty, integrity, or origin (or 
iimilar) of a message. This assurance can only be given if the engine operates 
correctly, even in the presence of certain threats (which the designer will 

typically be aware of). The engine should be trusted, for example, not to release 
unencrypted data when encrypted data is required. 



SI 
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Examples of cryptographic engines are the Capstone chip, a Fortezza Card, an 
encryption daughter board for a PC, and a software module in a program such as 
PGP. 

Endpoint Attack 

A typical endpoint attach may occur in the following manner. 

Consider a user who wants to sign an e-mail message. The user's private key is 
t3^ically stored in an encrypted state in a file on the hard disc of the user's 
personal computer. To create the signature, the user must enter a password or 
phrase which allows the file to be decrypted and the imencrypted private key 
temporarily stored in the computer so that ttie e-mail program can then perform 
the cryptographic calculations on the message to produce the signature using the 
private key. 

The signature created is an upwards of 64 ASCII character length string which 
imiquely correlates the user's private key with the digital representations of the 
message. 

" Consider an endpoint attack which modifies the behaviour of the users e-mail 
program. It would be possible for the malicious program to read and then store 
the various keys used by the user (in particular the key strokes that comprise the 
pass word or phrase) in another location on the hard disc. Having knowledge of 
the pass phrase or a copy of the key/s allows the malicious program to sign 

• otiter messages, which the user did not intend to sign. For example, messages 
aufliorising the purchase and shipping of goods to a xmknown recipient could be 
created and signed, all without the authority or knowledge of the user. The 
Trojan horse program may also secretly communicate the private key or keys of 
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the user to another user, who could then fraudulently forge the user's digital 
signahire onto any document supposedly sent by the original user. 

This is the primary threat countered by the present invention. 

This invention provides a means for securing against the unauthorised use of a 
user's private key which as a consequence provides high assurance that the 
digital signatures created by that key are legitimate. The invention can be 
embodied in a number of forms each of which is useful in different applications. 

BRIEF DESCRIFnON OF THE INVENTION 

In a broad form of the invention a private key protection device (PKPD), 
comprises a digital private key storage means containing a user's digital private 
key; a cryptographic engine; a communications port for receiving digital data 
from an external device, and for transmitting data to said external device; a 
display means for displaying said received digital data; a user operable input 

connected to said cryptographic engine to indicate when operated by said 
their approval of said displayed received digital data; wherein said 
cryptographical engine is trusted to only apply said user's digital private key to 
sign received data only if said user operable input means is operated and 
communicate said signed data external of said digital private key protection 
device. 

Specific embodiments of the invention will now be described in some further 
detail with reference to and as illustrated in the accompanying figures. These 
embodiments are illustrative, and not meant to be restrictive of the scope of the 
invention. Suggestions and descriptions of other embodiments may be included 
but they may not be Ulustrated in the accompanying figures or alternatively 
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user 
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features of the invention may be shown in the figures but not described in the 
specification. 

BRIEF DESCRIPTION OF THE HGURES 

Fig. 1 depicts a pictorial representation of elements of an embodiment of a 
private key protection device; 

Fig. 2 depicts a further pictorial representation of elements of a further 
embodiment of a private key protection device; 

Fig. 3 depicts the use of a message envelope created by the PKPD; 

Fig. 4 depicts the use of a message envelope created by the PKPD; 

Fig. 5 depicts the PKPD attached to a PC wherein the device has an in built 
display; 

Fig. 6 depicts the PKPD attached to a PC wherein the device incorporates a 
keyboard/ video and mouse pointer switching function; and 

Fig. 7 depicts a network comprising devices attached to PC's in the network. 

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION 
When a user wishes to sign a document they created themselves or one that was 
received and has been amended, they use then: private key which is typically 
stored on the hard drive of their personal computer PC. Their private key is in 
encrypted form so that not just anyone can locate it and use or copy it, so the 
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users wUl need to input a pass phrase toown only to them to "unlock" use of the 
private key for the signing process. 

As discussed previously, it is during the time the private key is "unlocked" that 
the PC and user are most vulnerable to an "endpoint" attack. Even if the key is 
contained in a supposedly more secure device, such as a smartcard or a PCMQA 
. card such as a Fortezza card, it wiU be apparent to the reader that malicious 
software will still be able to utilise the unprotected key or the cryptographic 
services of the device. As soon as the device is unlocked (by the user entering a 
PIN), the device will perform whatever calculations it is asked to perform, 
whether the user is aware of ttiese or not. 

•n.e invention comprises a private key protection device (PKPD)which is capable 
of resisting "endpoint attacks" thus ensurirtg the safety of the private key at all 
times. 

In its simplest embodiment the PKPD exists separate from the user's PC but 
com^ects to it and its peripherals as required via normal communication ports. 
The embodiment depicted in Fig. 1 shows the PKPD 10 receiving 12 and 
transmitting data 14 via a communications port 16 of a device 18 which could be 
a PC. In this embodiment the PKPD Ues between the user 20 and the PC 18. 

The PC can send any data to the PKPD, which may be for example a shopping 
order list, a military command to fire a missUe, or a contract. The PKPD receives 
the data at its communications port 22 and directs the data to the display 24. 
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The display 24 displays to the user the data to be reviewed plus any other 
conunand or prompts required to enable the user to control the use of the 
"private key" which is stored in the private key storage means 26. 

Once the user has read and understands the document displayed, if they do not 
agree or are not v^dlling to authorise the meaning of its contents they can ignore it 
and the document will be removed by a reset of the PKPD or some such other 
approach which ensures that the document has been permanently removed from 
the PKPD. 

If the user agrees with or authorises tfie contents of the document, just as tiiey 
would in the paper domain, they can choose to digitally sign the document. 

This is achieved using the PKPD by manually operating the user operable input 
means 28 which may be integrated with the PKPD. This input means may be 
labelled variously, an ACCEPT button, a SIGN button, etc and may have various 
mechanical properties. For example, it may be a momentary contact sv^dtch, it 
may be locked and unlocked for manual operation and inoperable without a 
physical key, it may be backlit when operable, it may require a predetermined 
depression sequence. These features are merely additional to the primary 
requirement of being user operable in the physical sense. 

Once the user operable input means 28 is operated, the cryptographic engine 30 
will access the user's private key in ttie private key storage means 26 and use it to 
generate a digital signature of the document and only tfiat document which was 
displayed to the user. 
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Once the document is signed, it is transmitted to the PC 18 via the transmit data 
path 14 via both communications ports 22 and 16. A communications port is a 
device which transmits or receives digital data to/from another port using a 
common protocol. A communications port may comprise hardware (eg parallel 
"Centronics" printer port RS232 protocol port) or a logical software arrangement 
(eg TCP/IP port). The transmission and reception of digital data could be 
conducted via wire or wireless means. 

The electronic means to implement the above functions of the PKPD can be 
implemented by a person skilled in the art. 

A PKPD counters endpoint attacks and assuming that the cryptographic 
algorithms are not breakable, and that there is confidence in the public key 
distribution infrastructure, it becomes possible to trust the use of private keys. It 
becomes accepted that the person purported to have applied the signature 
actually did apply it, and will therefore be bound by the content and intent of the 
digital document that was signed by that user. This type of assurance is 
sometimes referred to as "non-repudiation". 

Thus the grocery store can be sure that the Jones' really do want the shopping list 
items in their message and if included, the authorisation of a credit card payment 
can be accepted without doubt prior to the shopping list items being deUvered. 
The military order to fire a misstte is real and if authorised by the appropriate 

military commander should be carried out without question. 
Digital Certificate 

A further use of a digital signature is to create a certificate which is a statement 
by tiie signer about another person or fact. A certificate is usually an indication 
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that the issuer of the certificate confirms certain information or that it has a 
particular property. 

In the paper domain a certificate is something which attests to a fact, like 
graduation from University. The certificate is typically hard to forge as it will 
normally have a seal that can only be applied by or with the authority of the 
Chancellor of the University. 

In practice there are other ways of verifying that a person has graduated from a 
University but the certificate is typically taken at face value. 

Digital signatures can also be used to uniquely sign a document which acts like a 
certificate. In some v^ys a digital certificate is better than a paper certificate since 
a digital certificate can be checked by an equivalent device to that of a PKPD for 
decrypting and checking the veracity of the private key used to create the 
certificate as well as displaying the document which could not have been altered 
while bundled with the certificate. 

The term certificate is frequently used to refer to a particular type of certificate, 
which is used to confirm a user's "public key" the second part of an asytiunetric 
key system where the first part is the user's "private key". Such "public key" 
certificates are typically created by a third party, flie third party being trusted 1^ 
all users to take a user's (a user known to the required level by the third party) 
public key and bimdle it into a "public key" certificate. 

Thus the second user in possession of the first user's "public key" certificate can 
be sure it is actually that user's public key. 
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once; used only to sign the data which has been displayed; and is only used if the 
user operable input means is activated by the user. 

The way in which this ftinctionality is created and the consequent high assurance 
evaluation of the PKPD are steps known to those skilled in the art after having 
been instructed of the arrangement of the invention. 

The terms trust, assurance and confidence were used to describe desirable and 
preferable features of the PKPD and in the art these terms are generally 
considered to be synonymous but others may also be used. 

Devices and systems including their methodology are often complex and 
interrelate with each other, hiunans and external influences in imexpected ways. 
However, device and system failure is unacceptable in so called critical situations 
and one such failure is in the failure of security in handling digital data. 
Designers of so called critical systems are obliged to demonstrate that their 
system has been implemented in such a way that the likelihood of failure is 
suitably low since it is very difficult to completely eliminate the likelihood of 
failure in any system. 

Qearly in the digital domain, failure is not only by way of failure to perform a 
particular function it is also the designed ability to resist the persistent attack of 
hostile or mischievous system users who want to take advantage of weaknesses 
in the system. 

The more critical the system is, the lower the acceptable likelihood of failure 
becomes and generally the lower it becomes the more expensive the system. 
Furthermore, the more complex the system becomes, the harder it is to achieve 
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an acceptably low likelihood of failure. Also, the more complex a system is the 
more difficult and expensive it is to evaluate the presence or absence of faults 
and bugs in the implementation. 

T1.US, we ashumans, learn to aUocatedifferentlevels of trust to various systems 
but the meaning of the term "trust" will always be a property of the context of ats 
use and our understanding of the likelihood of f aUure . 

Persons skilled in the art will generally recognise the property which makes a 
system trusted, but in some cases it will be necessary to explicitly define the 
property. 

•n.us in a PKPD as stated previously, it is preferable that it be trusted to use a 
stored key on the displayed documentand only usedif the user operable input 

means is activated, aearlythekey must be secured fromunauthorised access 
and may if desirable be stored in encrypted form. 

Inthe case ofapublickey,it must be stored so that it can not be altered in an 
unauthorised way. 

The display means 24 as depicted in Fig. 1 and used in other embodiments 
described in this specification is a device for converting data into a human 
readable form. Display technologies are everchanging examples of whichi^^^^ 

CRT monitors and LCD monitors. Other types of display indude printers and 
BraiUe output devices so that the sight impaired can perceive the data. 



even 



„ is preferable In *e context of *e important use of a PKPD that the monitor be 
trusted «, display exacdy the data presented .o i. and fta. the displayed lom of 
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the document be such that the user who observes the display can not, once 
having signed the data with a PKPD, declare that the data was not displayed 
accurately to them. 

Figs. 5 and 6 depicts PKPD's 40 and 50 respectively, each having their own 
monitors 46 and 62 and further in Fig. 6 the PCs monitor 56 can be used to 
display exactly the data to be reviewed by the user of the PKPD. 

Thus it may be that the data format is standardised in that all characters are a 
minimum size and predetermined font. It may also be important to filter the data 
to exclude all macro's or executable because it is important to be sure that only 
displayable data is reviewed and signed. 

Importantly, it is highly preferable that only that data which is displayed is 
signed by the predetermined key held in safe storage in the key storage means. 

The user operable input means 28 depicted functionally as a block in Fig. 1 could 
be in one of the various forms previously described, importantly, it v/ill be 
apparent to those skilled in the art that the means itself is a typically mechanical 
one that requires interaction of the human user and thus not operable by a rogue 
program. This means that the signal generated by the switch is not capable of 
being replicated by any equivalent signal generated even within the PKPD itself. 
In a highly critical environment where a PC and keyboard can not be trusted. 
This clearly obviates the use of a software equivalent or any combination of 
keyboard based keys associated with the user' s PC. 

It is also clear that there is preferably a degree of physical security related to the 
PKPD and the times at which it is being used by the user. The PKPD may 
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preferably require the user to ider^tify and authenticate to the PKPD before ,t 
functions as required. Such identification and authentication may involve the use 
of user id, password, pass phrase, PIN, token, biometric or other means, or 
combinations thereof. 

In this regard, it is possible as will be described in other aspects of the invention 
that thekeystoragemeansisphysically removable from the PKPD and although 

the keys are stored therein they can not be physically extracted, otherwise any 
attempt to do so wiU destn>y the keys and possibly the removable memory 
device itself. 

Furthermore, the operation of the PKPD can be predicated on the successful 
response toachallenge to the proper user by thePKPD.l^^e challenge could be 

in the form ofaquestionandapredeterminedresponsebytheuser.^^^e answer 
could require a further input to the PKPD in the form of a keyboard for example 
providing numeric or alpha numeric input for the response or a biometnc 
response in the form for example of a iris check by an appropriate sensor device 
included in the PKPD device (not shown). 

in addition to the physical requirement to operate the PKPD (eg insertion of a 
validkeystoragemeans(egSMARTCARDorFORT^ACRYFrOCARD)) 

and a valid challenge response, it may also be preferable to operate an audit log 
of all transactions performed or attempted with the device. 

An audit log comprises a coUection, typically strictly chronological, of 
informationrepresentative of all transactions performed by thePKPaSuchalog 

will identify (typically after the fact) those transactions which should not have 
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taken place and thus unauthorised use of the signature by even the authorised 
user will be available for scrutiny. 

Preferably security properties of an audit log include the inability to alter or clear 
the log and with this property intact it is possible to claim non-repudiation of the 
transactions in respect of the user performing the transaction. 

Although, the PKPD has been described and likely understood to be useable by 
only one user, it is possible for a PKPD to be useable by multiple users as long as 
it can partition the separate user's keys or alternatively accept multiple insertable 
key storage means. 

Fig. 2 depicts a further embodiment of the invention of a PKPD comprising 
similarly identified elements such as a commimications port 22, a display 24, a 
user operable input means (accept key) 28 but elements such as a cryptographic 
engine (30 in Fig. 1) are replaced or enhanced by the use of a CPU 30a, a RAM 
30b and a ROM 30C 

Additional elements comprise a smartcard interface 32 for the insertion of a 
smartcard containing a specific user's keys, and a video switch 34 for receiving a 
video signal from an attached PC, and passing that signal to the PCs monitor, 
except when the PKPD is active, in which case the PKPD's display information is 
passed to the monitor. Such an arrangement is depicted in Fig. 6 where the PKPD 
50 is located physically between the user's PC 52 and its monitor 56, keyboard 54 
and pointing device 48. 

If the PKPD uses the PC's monitor for display of information to the user, it is 
preferable to have an additional unforgeable indicator which can be used to 
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inform the user whether the information displayed on the monitor is trusted 
(coming from the PKPD) or not (coming from the PQ. An example of such an 
indicator may be a LED on the PKPD front panel, near the user operable input 
means 64 on Fig. 6. 

•mere is also a Private Key Storage means 38 for the PKPD's own private key the 
use of which will be discussed later in the specification. 

The video switch 34 of this embodunent is arranged to take over control of the 
user's own PC monitor and repUcate the trusted display function described 
previously. Thvs even if this embodunent did not have a display 24, it could still 
display die received data/document in a trusted manner on the user's PC 
monitor. Also refer to Fig. 6 for a depiction of such an arrangement. 

The smart card reader 32 aUows the PKPD to have a further level of security 
since the smart card containing the user's keys and other selected keys can be 
kept in a physically secure place until it is needed saving the need to physically 
secure the whole PKPD which invariably would have involved discomiectmg 
and storing a more bulky device than a smart card if connected with cables 
(wireless PKPD's are also possible). 

Furthermore as stated previously, multiple users can use the same PKPD. 

Yet further this embodiment has the provisions to apply a signature unique to 
the PKPD itself. This provides furttier surety to the recipient that the user's 
signature was indeed created on a PKPD, and not on, say, an untrusted PC. This 
could indicate to the recipient that the originator was willing to be legally bound 
by the message, and that the originator would not be able to repudiatehaving 
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sent the message. (Contrast this with a message without the PKPD signature: flie 
originator could establish reasonable doubt about the fact that he deliberately 
signed the information, by proposing the plausible scenario in which a virus or 
Trojan horse on his PC signs information with his signature, without his 
knowledge). The existence of a PKPD signature assures the recipient that a PKPD 
was used by the originator and furthermore increases the non repudiation factor 
of the originator. 

The PKPD could be constructed in such a way as to interpret organisational 
policy before permitting information to be signed with an organisation's 
signature. For example, it may be that the PKPD will only sign a message with a 
company's private key (which is stored inside the PKPD) if at least two of the 
company's directors have individually signed the message. 

A certificate issuer could use a PKPD to create certificates. The certificates could 
be signed twice, once using the issuer's personal private key, and the second time 
using the PKPD private key. Any person wishing to rely on such a certificate in 
the future could have greater confidence in the fact that the issuer deliberately 
intended the certificate to be signed, because of the presence of the PKPD 
signature. In contrast, if the issuer's PC was infiltrated by malicious software, 
that software could create any certificates it wanted, and if the issuer's private 
key were available to the PC (either directly, or via a smartcard or Fortezza card), 
the certificate could be signed with that key without die issuer's knowledge or 
consent 

Fig. 3 depicts a message text (docimient) which has been first signed by User B's 
public key (ie can only be decrypted (unbundled) by User B's private key) and 
the signed document is then signed again by the User B's PKPD public key (ie 
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tt,e result can only be d«rypKd (unbundled) by a co^sponding PKPD private 
key). 

TO,anangem«n,providesamessagewWchcanonlybedecryp«dwia,bo**e 
privatekeyofUserBandfteprivateteyofUserB-sPKPDftwouWbepossible 

to construct the PKPD to dispUy the decrypted version of such messages to User 
B. but to ensure that fte deaypted version was never released outside the PKPD. 
This would n«an that althou^ User B could view the decrypted infomuHon on 
his screen, he wouldn't be able to print it, save it on disk, or forward it to any 
other user. Such a property can be referred to as an "Eyes Only" property. 

An improvement in this mectanisn. would bebuseaPKPD shared key,ins*«d 

erf the User B PKPD's public key to perform fte second encryption. This would 
allowamobUeUserBto read the message at any convemen,PKPD,ra.her than 

at only the specific one whose public key was used. 

Fig 4 depfcts the same User B pubUc key use so that the inner layer can only be 
read by UserBbutthe outer layer is signed by the PKPD-sshared key so that any 

PKPD can remove the outer layer . 

In this exampleaShared Key isused, meaning that the encryption wWch 
partof the signature processusesasinglesynunetric key heldby every PKPD 

and thus only PKPD-s having that shared key may remove the outer layer. 

Outer and inner layers are akin to the inner and outer envelopes of the SAFE 
HANDS document protocol in the paper domain. 
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In a further embodiment there exists a mechanism for receiving the 
document/message from a computer, and transmitting the signed document to 
its next destination directly from the PBOPD via its communications port using a 
physical layer transport mechanism such as Ethernet, serial, parallel, PQ, SBUS, 
SCSI, VSB etc. Thus this mechanism excludes tiie transmitted signed document 
travelling back to the computer from which it was received. 

In a yet further embodiment of the PKPD it would not only perform a signature 
generation function but also be capable of validating signed documents received. 

The process of validating a digital signature is subject to endpoint attack. For 
example, a malicious e-mail program could inform the user that the signature 
attached to a message was valid, when this was not the case. In fact, a malicious 
e-mail program could display to the user any message it wanted to, as well as 
asserting that the message was signed in a most trustworthy way, even though 
no such message had ever been signed or sent. 

A PKPD can be used to counter such endpoint attacks. The process of validating 
a digital signature involves the use of a public key. The PKPD, on being 
presented with a signed message, can calculate the validity of the message with 
respect to the public key, and then display the message contents and the 
signature validity to the user. 

In general, a PKPD would not be configured with a public key for every potential 
originator. Instead, a certificate hierarchy is likely to be used, involving a single 
"root" certificate (typically self-signed), from which other certificates can be 
validated, eventually assuring the relationship between the originator and the 
originator's public key. The PKPD, on being presented with a signed message for 
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vaUdation, as well as the appropriate chain of certificates (typically retrieved 
from a directory) can calculate the vaUdity of the certificate chain, as well as the 
validity of the message. The contents of the message and signature validity, as 
well as the certificate chain details, can be displayed to the user. 

The protection of the root certificate is important. An attacker who could modify 
the root certificate could supply a complete chain of "bogus" certificates, which 
would be vaUd with respect to the modified root certificate. Current e-mail 
programs are vulnerable to this threat. A PKPD would have to store the root 
public key in a manner which would prevent its unauthorised modification. 
Physical and procedural means could be used to provide this security. 

A yet hirther embodiment of the use of a PKPD is to incorporate into the 
message being signed an "indicator" which can act as a flag to network security 
devices that there is an authentically signed message witiun the outer layer/s. 
The network security devices then may allow the signed document to leave, let 
us say a high security network for a network of lower security. This "indicator" 
can indicate that the message has been sealed and that it is safe for the message 
to be transported via insecure communication means (eg the Internet) to its 
intended destination. It is thus possible to raiplement a multi-level secure (MLS) 
messaging system. Fig. 7 is an illusbration of various PCs and associated PBCPD's 
conununicating via local and Internet networks. 

In another embodiment the PKPD would be programmed to produce signahires 
using standard protocok, such as MSP,CSP (ACP-120),S/MIME,PGP, etc.. This 
would have the advantage that commercial off the shelf infrastructure used 
elsewhere would "understand" the signature, although it may not fuUy 
appreciate the high assurance nature of such signatures. 
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In some protocols, such as MSP, CSP, S/MIME, where there can be two 
signatures, the device can offer advantages over those mentioned above. The 
PKPD can create one signature using the user's private keys, which may be used 
for purposes unrelated to the devices' invention, A second signature can be 
created using special keys devoted solely to the function of the PKPD. 

A user may have private keys which are used for a variety of functions apart 
from the ones described in this document. For example, keys may be used for 
the authentication and establishment of a remote login session over the Internet 
Another embodiment of the PKPD could accept requests from the connected PC 
that would ordinarily have been dealt with by a smartcard or Fortezza card 
connected directly to that PC. The PKPD would preferably alert the user to the 
fact that the keys were being used (although it would not necessarily be able to 
indicate to the user for exactly what purpose they were being used), before 
performing the appropriate signature, validation, encryption, or decryption (or 
other) operation. Although such a system would potentially allow the user's key 
to be abused by malicious software, the PKPD's own private key would not be 
made available in the same way. Its use would be reserved for instances in which 
the user is able to make an informed, deliberate, and legally binding choice to 
sign the document after it has been displayed by the PKPD. 

A PKPD will be able to create a second signature, using special keys, to indicate 
the high assurance nature of the signature. Preferably, the usefs keys would be 
used to create an inner signature, which would be encompassed by the second 
signature created by, for example the Fortezza Crypto card, using the PKPD's 
private key. 
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A signature vaUdating device being a slight variant of a PKPD can thus translate 
the twice signed document into a conventional document while providing the 
necessary assurance of its originator and the particular PKPD which applied the 
signatures. 

In large financial instituHons, it is not practical to have "manually" signed 
dieques. Instead, the signatures are printed (by machine) onto the cheques. If it 
were possible for malicious software to be introduced into such a system, 
cheques could be obtained improperly. It would be possible to use PKPDs to 
secure the cheque printing process. An authorised user would have to review the 
appropriate details for the cheques, and then "accept" them on the PKPD, which 
would sign a message containing the details. Another PKPD, connected directly 
to the cheque printer, would verify that every order to print a cheque had been 
signed by a PKPD. Since the graphic containing the authorising (printed) 
signature is stored only within this latter PKPD, it would not be possible to print 
illegitimate cheques without using the PKPD. This would counter the threat of 
maUcious software. The printer will need to be connected directly to the PKPD. 
Since the graphic containing the authorising (printed) signature is stored only 
within the PKPD, cheques appearing with the particular graphic could only have 
been produced with a high assurance PKPD. Such a signature would be unique 
to the printed content of the cheque (be that the amount, the words describing 
the amount, the date, the time, the payee and a unique transaction number). 

The PKPD could be programmed to display information in particular formats 
which are in a convenient human readable form. For example, if messages are 
written in Hyper Text Markup Language (HTML), the device could render the 
HTML, instead of showing all of the tags of the generated signahire within the 
message. 
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High value electronic transactions may be required to be authorised using a high 
assurance PKPD and to facilitate easier transactions, the PKPD monitor would 
display Secure Electronic Transaction (SET) messages in a form convenient to the 
PKPD user. 

The device of the invention is preferably able to check the authority of the user to 
sign certain types (eg. classifications) of messages, before proceeding to allow a 
user to do so. The user's authority could be stored vdth the keys, or in 
certificates communicated to the device with the message or at any other time. 

The device of the invention is preferably able to encrypt information being 
transmitted, in order to preserve the confidentiality of the message content until 
it is decrypted by the recipient. 

High assurance digital signature device 

A preferred embodiment of the high assxurance digital signature device 
comprises an embedded microprocessor which executes a program stored in 
ROM, Preferably the ROM and microprocessor are mounted on the same 
integrated circuit chip and arranged so that elements within the circuit cannot be 
changed so that the integrity of the device as created can not be interfered wifli. 

Interfaces 

hi a preferred embodiment there are three operational interfaces: 
Network Interface 

In one embodiment the device contains an Ethernet network interface, and 
communications vnth the user's personal computer occurs over the Ethernet. 
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The choice of this network protocol allows flie device to be used with a wide 
variety of f>ersonal computera, work-stations, X-terminals, and other networked 
computers. 

In some environments, it may be possible to assume that all user's computers 
will have, for example, SCSI or bi-directional parallel interfaces. There is also no 
reason that these could not be used for communication with the device. 

User Interface 

In a further embodiment interfaces to the user may be categorised as bulk inputs 
or outputs or Boolean inputs or outputs. 

1. A Boolean output interface could be as simple as a light emitting diode 
(Le.d.) Such an output only needs to indicate whetiier the bulk output interface 
is active or not. When the Le.d. is lit, it may indicate that the device has taken 
over the user's screen as described in a previous embodiment 

2. The preferred bulk input interface is the keyboard of the user's computer. 
In other trusted systems a keyboard switch has been used to divert the output 
data from the keyboard to a different destination. Similar technology is used in 
this embodiment to divert the representations of keystrokes on the keyboard or 
other input device to the PKPD, instead of the user's computer. An alternative 
mechanism is to have a keypad or keyboard built into the PKPD. A bulk input 
device is used for the entry of data, such as, personal identification (PIN) phrases 
etc. 



3. The preferred bulk output interface is the monitor of the user's personal 
computer. Just as the keyboard switch described above is used to "takeover" the 
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keyboard, a video switch is preferably used to allow the device to "takeover" the 
monitor. Any output displayed on the monitor by the device can be trusted to be 
the output provided from the bulk mput interface. The user can tell whether the 
information on the monitor is that supplied from the device or not, by checking 
the status of the Boolean output which, for example, may be a light emitting 
diode (l.e.d.). A monitor may also be built into the PKPD. Figs 5 and 6 display 
these two arrangements. The PKPD 40 in Fig 5 is merely connected to the users 
PC 42 communication port and has its own screen 46 and a user input means 44. 

4. A preferred Boolean input device is a simple push button switch mounted 
on the device. With such a switch, the user can provide a positive indication to 
the device that the docxmient being displayed on the bulk output interface is 
acceptable. This switch is referred to previously as a user operable input means. 

User's Fortezza Crypto card Interface 

In one embodiment the user is able to insert their Fortezza Crypto card into the 
device. This allows the PBCPD to authenticate the user, by checking that the user 
has entered the correct PIN phrase for the Fortezza Crypto card, and it also 
provides a convenient secure storage for the user's private keys used for 
encrypting messages if need be. 

Functions of the PKPD 

In one embodiment the PKPD can be arranged to provide a limited range of 
functions. Using the "client - server" model, the PKPD can be described as a 
server. Note that this does not imply that it is a large machine, located in a 
special room, and shared by many users at once. In this embodiment it means 
that the PKPD does not initiate actions itself, it only responds to requests from 
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another system or device, which is for the purposes at hand referred to as a 
client. 

The client, typically a user's personal computer, sends requests to the PKPD. 
After performing the appropriate hmction as determined by the request, the 
PKPD sends a reply back to the client. 

In a preferred embodiment a niraiber of f imctions which could be offered by 
such a device include login; set personality; submission and delivery. 

An important aspect of the submit function is the seau*e manner of reviewing 
and signing operations conducted by the PKPD. The PKPD is arranged to make 
it impossible for the message to be modified between the reviewing and signing 
steps of the process but this does not imply that after reviewing the message the 
signing function must occur. 

Secure Messaging 

The following is a description of an embodiment of the way in which a high 
assurance digital signature device and method of use can be integrated into an 
existing messaging system which uses the MSP (Message Security Protocol) and 
a Fortezza Crypto card. A similar approach could be used for systems using 
other protocols. 

Existing system 

The typical messaging system incorporating MSP performs the login and 
message submission processes as follows which is in accordance with MSP ICD. 
Note that although the order of some steps is important, the precise order 
described herein is not the only valid process. 
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1. The user starts a Messaging User Agent (MUA) program, such as 
Netscape, Exchange, or Notes. As part of the start-up sequence, the user is 
required to login to the Fortezza Crypto card. The MUA program provides a 
pop up box, into which the user is asked to enter a PIN phrase. The PIN phrase 
is passed as an argument to the MSP_ LOGIN call. 

2. The MSP^LOGIN function passes the PIN Phrase to the Fortezza Crypto 
card, which verifies it, thus authenticating the user. 

3. The MSP^LOGIN function instructs the Fortezza to provide a list of 
personalities/ whose private keys are stored on the card. 

4. The MSP_LOGIN function returns, passing tfie list of personalities as a 
result. 

5. The MUA program displays the list of personalities to the user in another 
dialog box. The user is invited to select one of the personalities with whose key, 
messages vdll be signed, encrypted, or decryption. 

6. The MUA program passes the selected personality as an argument to the 
MSP.SETPERSONAUTY function. 

7. The MSP_SETPERSONALITY function instructs the Fortezza Crypto card 
to select the appropriate private key. 

8. When the user chooses to send a new message the MUA program creates 
a window for the new message, and the user chooses a recipient/ s (either by 
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typing in addresses or choosing them from an address book), types in the 
message, and adds attachments if necessary. The user then selects the required 
security services: either none, sign, or sign and encrypt When the composition is 
complete, the "Send" button is activated. The user's computer may or may not 
have control of the user's ability to attach certain files. 

9. Submission access control then occurs. 

10. The MUA program then begins the process of invoking none or "one or 
more" security options. For example, the Fortezza Crypto card is instructed by 
flie MUA program to calculate a hash value (eg. MD5) and signature, and if 
appropriate, to enoypt the message. The signature and plain or encrypted 
message are constructed into a "Protocol Data Unit" (PDU) according to the 
protocol. 

11. The PDU is attached to header or "envelope" information, which is then 
transferred to the messaging server, or Message Transfer Agent (MTA). 

12. The typical delivery and verification/decrypted mechanism then follows^ 

Modifications to provide a high assurance mechanism 

The following steps show the modifications required to change the existing 

system so that it can support the high assurance mechanism. 

1. When the MUA is loaded, instead of loading in the standard MSP 
software as an integral part, software is loaded to allow the MUA to 
communicate with the PKPD. When the MUA calls the "MSP _ LOGIN" 
function, the software sends a signal to the device to indicate that the login 
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function should conunence. The device allows the user to enter the PIN phrase 
through a built-in keypad (or through the computer's keyboard, if keyboard 
switching functionality is included). 

2. The device returns a signal to tiie computer, including the listed 
personalities. The software receives the signal, and "returns" the list as the result 
of the MSP _ LOGIN call. When the user chooses a personality, the MUA is 
loaded. 

3. When the MUA software would normally call the 
MSP^SETPERSON AUTY function, the appropriate parameters are instead 
transmitted to the PKPD. The PKPD displays the chosen personality to the user, 
and allows the user to verify ttiat this is appropriate. This protects the user 
against the threat of malicious software choosing an inappropriate personality 
for messages about to be signed by the user. The "results" of the 
MSP.SETPERSON ALITY function would be returned to the MUA. 

4. When the MUA would previously have requested the card to hash and 
sign particular data, the function would instead be routed to the PKPD, in a 
similar way. The information being signed woidd be displayed to the user, and 
the user would have to indicate acceptance before the signature value was 
released back to the MUA. To perform this function, the PKPD may have to 
interpret appropriate protocol data imits in order to present a human readable 
version of the message to the user. 

A preferable high assurance digital signature mechanism provides one or more 
of the following features: 
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1. A message which is signed with a high assurance signature should not be 
vulnerable to Trojan horse software attacks on the computers of either the 
originator or receiver. That is, it is assumed that the software on all the systems 
have been maliciously changed to subvert the security of the computer but even 
those maUcious changes will not affect the functions of a PKPD in its signing or 
verification functions. 

2. Subject to the strength of the cryptographic algorithms it should be 
impossible to forge a high assurance signature. 

3. The high assurance signature can preferably be conveyed within standard 
protocols, thus allowing a user with Commercial Off the Shelf (COTS) standard 
compliant software to receive messages from, and transmit messages to, a user 
using a High Assurance Digital Signature device and method. 

4. The user should preferably be allowed to use their Fortezza Crypto card 
in an un-trusted computer for un-trusted applications. 

It wiU be appreciated by those skilled in the art, that the invention is not 
restricted in its use to the particular application described and neither is the 
present invention restricted in its preferred embodiment with regard to the 
particular elements and/or features described or depicted herein. It will be 
appreciated that various modifications can be made without departing from the 
principles of the invention, therefore, the invention should be understood to 
include all such modifications within its scope. 
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THE CXAIMS DEFINING THE INVENTION ARE AS FOLLOWS: 

1. A digital private key protection device, comprising 

a digital private key storage means containing a user's digital private key; 
a cryptographic engine; 

a communications port for receiving digital data from an external device, 
and for transmitting data to said external device; 

a display means for displaying said received digital data; 

a user operable input means connected to said cryptographic engine to 
indicate when operated by said user their approval of said displayed received 
digital data; wherein 

said cryptographic engine is trusted to only apply said user's digital 
private key to sign said received data only if said user operable input means is 
operated and communicate said signed data external of said digital private key 
protection device . 

Z A digital private key protection device according to claim 1, wherein said 
digital key storage means contains a trusted public key and a plurality of user's 
public keys signed by said trusted private key; and said cryptographic engine 
validates signature of said user's public key v/ith said trusted public key to 
determine the veracity of said user's public key and then decrypts said received 
data using said verified predetermined user's public key and causes said display 
to indicate whether said user's private key was used to sign said received digital 
data. 

3. A private key protection system according to claims 1 and 2 wherein 
said signed digital data is a digital certificate. 
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4 A private key protection system according to claim 1 further compnsmg 
an audit means wherein signed data is not transmitted external of said digital 
private key protection device until a said encryption process is audited by said 
audit means. 

5. A private key protection system according to claim 2 further comprising 
an audit means wherein signed data is not displayed until a said encryption 
process is audited by said audit means. 

6 A private key protection system according to claim 1 wherein said digital 
private key protection device further comprises a private key protection device 
private key storage means wherein digital data signed by said private key 
protection device after operation of said user operable input means is further 
signed by said private key of said private key protection device. 

7. A digital private key protection device according to claim 1 wherein 
said digital key storage means contains a predetermined digital private key 
protection device's pubUc key; such that when said communications port 
receives signed digital data from an external device which may or may not have 
been signed by a said predetermined digital private key protection device; 

said cryptographic engine decrypts said received data using said 
predetermined digital private key protection device's public key to verify 
whether said digital private key protection device's private key was used to sign 
said received data. 

8 A digital private key protection device according to claim 7 wherein 
said display means indicates whether said digital private key protection device's 
private key was used to encrypt said received data. 
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9. A digital private key protection device according to claim 1 further 
comprising a public key storage means containing a plurality of user's public 
keys; and 

said received digital data contains information that predetermines which 
user's public key is used to sign said received data that is transmitted external of 
said digital private key protection device to said predetermined user. 

10. A digital private key protection device according to claim 1 wherein 
said cryptographic engine is trusted to decrypt digital data using said user's 
digital private key and passing decrypted digital data to said display means for 
display of said received digital data. 

11. A digital private key protection device according to claim 10 wherein said 
cryptographic engine does not decrypt signed digital data imless said user 
operable input means is operated. 

12. A digital private key protection device according to claim 10 wherein said 
commimications port can not transmit said decrypted digital data. 

13. A digital private key protection device according to claim 12 wherein said 
communications port can not transmit said decrypted digital data unless said 
user operable input means is operated. 

14. A digital private key protection device according to claim 1 wherein said 
digital private key storage means also contains a digital shared secret symmetric 
key wherein said cryptographic engine is trusted to only apply said digital 
shared secret symmetric key to encrypt data only if said user operable input 
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15 Adigi.alprtvateWFOt««<'"''--^°'<''"8'°-''P'""''"«''7 
.herein«idreceiveddigiMdatacon.ainsa„i^tn.ctionwHchde.ennineshow 

said encryption engine slould encr«>t or decrypt respectively. 

M Adigi.aiprivatelceypro.ectiondevicea<»rding.oanyprecedingdaim 

wl.erein.aid,eceiveddigitaldatacon.ainsaninstruc.ionwhichde.ernunes 

„hichpr„«KoIisusedbysaiddevicetoconm.«nica.eencryp.edors,gnedda.a 

external of said device. 

17 Adigitalprivatekeyprotecaondeviceaccordingtoanyprecedingdaim 
whereinsaid display mean. isextema.to,aiddevice,.»icon.rolledby said 
device for displaying data transnutted from said connmonications port 

18 Adigitalprivatelc^protectiondeviceaccordingtoanyprecedingclaim 
«hereinsaid«seroperaHeinp«.meansisextemal«.saiddeviceandcon.rol,ed 
by said device to be aauated by said user in a predeten^ned n«nner. 

19 Adigitalprivatekeyprotectiondeviceaccordlngtoanyprecedingclain, 
tether comprisi„giden.ificationa™lau.i«ntica«onmeans.ctuatedby said user 

in a predetermined maimer. 

20. Adigitalprivatekeyprotectiondeviceaccordingtod^mlSf^ 
_prisinglauditmea,.wbichaudi.ssaidactuati«,ofsaid«ser„lent*ca.»n 

input means. 
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21. A digital private key protection device according to any preceding claim 
wherein said digital private key storage means is removable from said device. 

22. A digital private key protection device according to any preceding claim 
wherein a cryptographic request is received from said external device according 
to a predetennined application programming interface, such that the request is 
performed by said PKPD using the user s private or other keys as identified by 
the request, but excluding the private key protection device with the result being 
transmitted to said external device or a predetermined destination included in 
said request or otherwise predetermined. 

23. A digital private key protection device according to claim 22 wherein said 
device displays a description of said request to the user and, only if the user 
operates said user operable input means, does said device carry out said request. 
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